Kontrola MQTT na żywo

wskazówka

Kontrola MQTT na żywo jest przeznaczona do żywego sterowania. W celu wysyłania harmonogramów z wyprzedzeniem, zobacz Sterowanie MQTT według harmonogramu zamiast tego.

Niniejszy przewodnik pomoże Ci skonfigurować MQTT na Twoim SmartgridOne Controller, aby zdalnie kontrolować i monitorować instalacje baterii i paneli słonecznych.

Co potrzebujesz

1. SmartgridOne Controller z dostępem do Internetu.
2. Dane uwierzytelniające MQTT: Możesz je uzyskać, wysyłając e-mail na adres support@eniris.be.
3. Środowisko deweloperskie Pythona (lub dowolny inny klient MQTT). Niniejszy przewodnik wykorzystuje prosty przykład napisany w Pythonie, aby wprowadzić Cię w świat MQTT i wysyłania poleceń. Zalecamy używanie Pythona ze względu na łatwość obsługi, ale każdy inny klient MQTT jest również wspierany.

Dodatkowe informacje

MQTT to szybki protokół komunikacyjny w Internecie. To system wiadomości publikuj/subskrybuj, który pozwala na bezpośrednie połączenie między Twoją maszyną a SmartgridOne Controller. Twoje zasoby są klasyfikowane w grupy: słoneczne, baterie, EV i HVAC.

Konfiguracja po raz pierwszy (Punkt wyjścia dla nowych użytkowników)

Mam SmartgridOne Controller, który chciałbym skonfigurować do zdalnego sterowania MQTT.

1. Sprawdź swoją sieć

Upewnij się, że Twoja sieć pozwala na ruch sieciowy mqtt przez port 1883. Możesz to sprawdzić, używając polecenia:

nc -zv mqtt.eniris.be 1883

Gdy to polecenie jest niedostępne, możesz alternatywnie pobrać i wykonać ten kod python.

W razie wątpliwości skonsultuj się z inżynierem sieci lub tymczasowo użyj hotspota 4G/5G swojego telefonu, gdy wystąpią błędy połączenia.

notatka

Gdy port 1883 nie jest dostępny w Twojej sieci, oferujemy kopię zapasową na porcie 80. To można skonfigurować w kliencie MQTT na późniejszym etapie tego podręcznika.

2. Dodaj swoje urządzenia

Zaloguj się do interfejsu uruchamiania i upewnij się, że urządzenia zostały dodane do SmartgridOne Controller.

3. Dodaj zewnętrzny sygnał MQTT

4. Włącz zdalny sygnał MQTT

Pole 'VPP ID' musi pozostać puste.

Czas oczekiwania mechanizmu awaryjnego informuje SmartgridOne Controller jak długo powinien czekać na nowe polecenia. Gdy SmartgridOne Controller przestaje odbierać polecenia, automatycznie przyjmuje domyślną strategię po tym czasie.

Następnie zaznacz wszystkie urządzenia, które chcesz uwzględnić w Zdalnym Sterowaniu MQTT.

5. Zdalny sygnał został dodany

Interfejs Zdalnego Sterowania MQTT został teraz aktywowany na SmartgridOne Controller.

Jesteśmy teraz gotowi, aby wysłać kilka podstawowych poleceń za pomocą prostego przykładu. Kolumna Status informuje, czy jakieś polecenie jest aktywne.

Skrypt demonstracyjny Pythona

Dobrą punktem wyjścia byłoby przetestowanie nowo skonfigurowanej integracji za pomocą prostego przykładu.

Ten kod testowy wykonuje prostą pracę, nieprzerwanie wysyłając następujące polecenia:

• Bateria: Ładowanie z mocą 5 kW
• Słońce: Ustaw moc na 0 kW

SmartgridOne Controller nieprzerwanie odpowiada wiadomością 'feedback' zawierającą zaobserwowane wartości mocy w sieci i zasobach. Ta funkcja jest również zawarta w tym przykładzie.

Proszę pobrać plik poniżej w preferowanym IDE Pythona. Wprowadź swój numer seryjny i dane uwierzytelniające MQTT, a następnie uruchom skrypt:

Gdy powyższe powiedzie się, możesz przejść do wysyłania innych typów poleceń. Wszystkie polecenia opisane są w naszej Dokumentacji Zdalnego Sterowania MQTT.

Dokumentacja MQTT do wysyłania poleceń

Ta sekcja szczegółowo opisuje format wiadomości MQTT i wymagania dotyczące ładunku do zdalnego kontrolowania polityki zasilania na urządzeniach w sieci SmartgridOne Controller.

Temat MQTT

Temat MQTT używany do wysyłania poleceń jest zorganizowany w następujący sposób:

standard1/rp_one_s/remoteControlMetrics/'controller SN'

Gdzie 'controller SN' powinien być zastąpiony rzeczywistym numerem seryjnym SmartgridOne Controller, który zamierzasz kontrolować.

Struktura ładunku MQTT

Polecenia są wysyłane jako ładunki JSON. Struktura ładunku jest zaprojektowana w celu wskazania różnych polityk zarządzania mocą i punktów ustawczych dla różnych komponentów systemu inteligentnej sieci. Oto zarys ładunku z opisami poszczególnych pól:

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": "<Unix Timestamp>",
    "fields": {
        "<Component Policy>": "<Policy Type>",
        "<Component Power Setpoint>": <Setpoint in watts>
    }
}

Opis pól

wskazówka

Wiele typów urządzeń (np. baterie + słońce) można kontrolować jednocześnie.

• extraTags (Object):
  • nodeId (String): Unikalny identyfikator dla węzła w sieci SmartgridOne Controller. To jest równoważne Twojemu numerowi seryjnemu, a następnie '_site_0' dla większości urządzeń SmartgridOne Controller.
• time (Integer): Znacznik czasu Unix w sekundach, wskazujący czas, kiedy wiadomość jest wysyłana.
• fields (Object):
  • <Component>_policy (String): Typ polityki dla komponentu. Jest to opcjonalne, a jeśli nie zostanie określone, system przejdzie do domyślnego ustawienia SmartgridOne Controller.
  • <Component>_power_setpoint_w (Float): Pożądany punkt ustawczy mocy w watach dla komponentu. To jest opcjonalne i ma znaczenie tylko wtedy, gdy określona jest odpowiadająca polityka.

Komponenty i Polityki

informacja

Zasoby tego samego typu (np. dwie baterie) będą łączone jako jeden komponent. Na przykład, gdy zainstalowane są dwie baterie o pojemności 5 kWh, będą traktowane jako jedna bateria o pojemności 10 kWh.

Każdy komponent w obiekcie fields może zawierać politykę i punkt ustawczy mocy. Następujące komponenty mogą być kontrolowane:

• solar_policy i solar_power_setpoint_w:

  • Kontroluje politykę generacji energii słonecznej i punkt ustawczy. Wspierane polityki:
    • Polityka punktu ustawczego: Ustaw maksymalną moc produkowaną przez wszystkie podłączone instalacje słoneczne razem. Pole solar_power_setpoint_w powinno być ustawione na limit mocy produkcji w watach.
    • Polityka ograniczenia wprowadzenia: Produkcja pełnej mocy, zgodnie z aktualnymi limitami sieci.
    • Polityka kosztów: Umożliwia minimalizację kosztów (rynek EPEX Spot) dla produkcji energii słonecznej z wyprzedzeniem. Gdy występują ujemne ceny wprowadzenia, ograniczamy produkcję do własnego zużycia. Gdy zarówno cena poboru, jak i cena wprowadzenia są ujemne, wyłączamy wszystkie instalacje słoneczne. Pole solar_power_setpoint_w jest ignorowane.
    • Polityka wyłączona: Wyłącza wszelką interakcję dla wszystkich zasobów słonecznych. Ostrzeżenie: limity nie są chronione w tym trybie. Pole solar_power_setpoint_w jest ignorowane.

• storage_policy i storage_power_setpoint_w:

• Kontroluje politykę systemu magazynowania energii oraz szybkość rozładowania lub ładowania.

  • Ustawienie polityki: Ustaw całkowitą moc ładowania (pozytywne ustawienie) lub moc rozładowania (negatywne ustawienie) dla grupy akumulatorów. Gdy podłączonych jest wiele akumulatorów, ustawienie jest dzielone przez dostępną moc ładowania/rozładowania, aby równomiernie obciążyć akumulatory. Pola storage_power_setpoint_w są ustawiane na żądaną moc akumulatorów.
  • Koszt polityki: Umożliwia optymalizację kosztów cen z wyprzedzeniem (rynek EPEX Spot) na akumulatorach, ładowając je w tanich godzinach i wykorzystując energię w drogich godzinach. Pole storage_power_setpoint_w jest ignorowane.
  • Samo-zużycie polityki: Umożliwia prosty algorytm samo-zużycia na akumulatorach. Nadwyżka produkcji energii słonecznej jest magazynowana w akumulatorze, a gdy słońce nie świeci, energia jest pobierana z akumulatora. Pole storage_power_setpoint_w jest ignorowane.
  • Polityka wyłączona: Wyłącza wszelką interakcję dla wszystkich zasobów akumulatorowych. Uwaga: limity nie są pilnowane w tym trybie. Pole storage_power_setpoint_w jest ignorowane.

• heat_pump_policy:

  • Przełącza systemy pomp ciepła w tryb on/off. Minimalny i maksymalny czas włączania będą zawsze przestrzegane.
    • Koszt polityki: Umożliwia optymalizację kosztów cen z wyprzedzeniem (rynek EPEX Spot) na pompach ciepła. Lokalny algorytm dynamicznego ustalania cen decyduje o najlepszych okresach włączenia.
    • Samo-zużycie polityki: Włącza pompy ciepła, jeśli produkowana jest nadwyżka energii słonecznej.
    • Polityka wyłączona: Wyłącza pompy ciepła.
    • Polityka włączona: Włącza pompy ciepła.

• switched_load_policy:

  • Przełącza systemy kontrolowane przez przekaźniki w tryb on/off. Mogą to być wbudowane przekaźniki lub przekaźniki podłączone do sieci.
    • Koszt polityki: Umożliwia optymalizację kosztów cen z wyprzedzeniem (rynek EPEX Spot) na przekaźniku.
    • Samo-zużycie polityki: Włącza przekaźnik, jeśli produkowana jest nadwyżka energii słonecznej.
    • Polityka wyłączona
    • Polityka włączona

• variable_power_load_policy oraz variable_power_load_power_setpoint_w:

  • Zarządza polityką zużycia energii przez pojazdy elektryczne oraz ustawieniem.
    • Ustawienie polityki: Ustaw całkowitą moc ładowania dla grupy EV. Pole variable_power_load_power_setpoint_w jest ustawiane na pożądaną moc ładowania.
    • Koszt polityki: Umożliwia optymalizację kosztów cen z wyprzedzeniem (rynek EPEX Spot) na akumulatorach, ładowując je w tanich godzinach. Pole variable_power_load_power_setpoint_w jest ignorowane.
    • Samo-zużycie polityki: Umożliwia ładowanie, jeśli produkowana jest nadwyżka energii słonecznej. Pole variable_power_load_power_setpoint_w jest ignorowane.
    • Polityka wyłączona: Wyłącza wszelką interakcję dla wszystkich zasobów EV. Pole variable_power_load_power_setpoint_w jest ignorowane.

• site_policy oraz site_power_setpoint_w:

  • Zarządza limitami eksportu miejsca.
    • Polityka eksportu: Ustaw limit eksportu dla miejsca. Pole site_power_setpoint_w jest ustawiane na limit eksportu.
    • Polityka domyślna: Przypisuje limit miejsca do domyślnej mocy eksportu, ustawionej w konfiguracji kontrolera.

Kontrola urządzeń

Specyficzne urządzenia mogą być również kontrolowane, zamiast grup urządzeń na podstawie ich typów. Komunikat ma identyczną strukturę:

• nodeId_policy oraz nodeId_power_setpoint_w

informacja

Gdy dwie komendy są wysyłane do tego samego zasobu (np. jedna komenda specyficzna dla urządzenia do inwertera słonecznego i komenda do wszystkich urządzeń słonecznych), metoda sterowania specyficznego dla urządzenia będzie miała pierwszeństwo przed sterowaniem typem urządzenia.

Zachowanie awaryjne

Dla każdego komponentu, jeśli _policy i _power_setpoint_w nie są określone, system automatycznie użyje polityki awaryjnej skonfigurowanej w SmartgridOne Controller. Zapewnia to, że każde urządzenie lub grupa urządzeń działa bezpiecznie i nadal funkcjonuje, nawet jeśli konkretne instrukcje nie zostaną dostarczone.

Jeśli żadna komenda nie jest wysyłana, po 60 sekundach (lub skonfigurowanym okresie czasu), domyślne polityki dla zasobów zostaną reaktywowane.

Anulowanie istniejących komend i powrót do lokalnych trybów kontrolnych

Aktywna komenda może być anulowana przez wysłanie komunikatu komendy awaryjnej.

Komenda awaryjna

Komenda awaryjna natychmiast anulowana istniejącą komendę, a SmartgridOne Controller przejmuje kontrolę nad instalacją. Wykonywana polityka zależy od tego, co jest ustawione w SmartgridOne Controller Ustawieniach.

Może być to również używane w przypadkach, gdy sygnał kontrolny wtórny, taki jak harmonogram, jest używany jako awaryjny.

Przykłady komunikatów:

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": "<Unix Timestamp>",
    "fields": {
        "<Component Policy>": "fallback",
    }
}

Pusta komenda

Pusta komenda może być wysyłana w każdej chwili, aby zbierać informacje o miejscu. Nie wpłynie na anulowanie bieżącej komendy i nie nadpisze komend z sygnałów kontrolnych o niższych priorytetach.

Pusta komenda ma następującą strukturę:

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": "<Unix Timestamp>",
    "fields": {}
}

Przykład ładunku

Poniżej znajduje się przykład ładunku do ustawienia różnych polityk i ustawień:

{
    "extraTags": {
        "nodeId": "OM12404080000000000_site_0"
    },
    "time": 1714652046,
    "fields": {
        "solar_policy": "setpoint",
        "solar_power_setpoint_w": 5000,
        "storage_policy": "setpoint",
        "storage_power_setpoint_w": -5000
    }
}

W tym przykładzie moc solarna jest ustawiona na generowanie do 5000 watów, a system magazynowania energii jest ustawiony na ładowanie lub rozładowanie z szybkością 5000 watów, w zależności od znaku wartości ustawienia. Jeśli którakolwiek z polityk solar_policy lub storage_policy została pominięta, odpowiednie urządzenie wróci do domyślnych ustawień określonych przez SmartgridOne Controller.

Dokumentacja MQTT dla otrzymywania informacji zwrotnej

Ta sekcja przedstawia strukturę i treść komunikatów zwrotnych wysyłanych przez SmartgridOne Controller za pomocą MQTT. Te wiadomości są publikowane na temacie standard1/outbound/remoteControlMetrics/feedback/<Controller SN> po przetworzeniu komendy.

Temat zwrotny MQTT

Temat zwrotny MQTT jest skonstruowany w następujący sposób:

standard1/outbound/remoteControlMetrics/feedback/<Controller SN>

Gdzie <Controller SN> należy zastąpić numerem seryjnym SmartgridOne Controller, który wysyła informację zwrotną.

Struktura ładunku zwrotnego MQTT

notatka

Wszystkie zasoby są grupowane według swojego typu. Oznacza to, że dwa indywidualne instalacje słoneczne o mocy 3 kW będą traktowane jako jeden zasób o mocy 6 kW.

Wiadomości zwrotne są sformatowane jako ładunki JSON. Te ładunki dostarczają szczegółowych informacji zwrotnych o stanie systemu po zastosowaniu komend ustawienia, z uwzględnieniem limitów sieci/urządzeń. Poniżej przedstawiono strukturę ładunku zwrotnego z opisem jego pól:

{
    "time": "<Unix Timestamp>",
    "data": {
        "state": {
            "grid": {
                "active_power_W": <Moc aktywna sieci w watach>,
                "today_imported_energy_Wh": <Importowana energia z sieci w watogodzinach>,
                "today_exported_energy_Wh": <Eksportowana energia do sieci w watogodzinach>,
                "import_limit_W": <Limit importu sieci w watach>,
                "export_limit_W": <Limit eksportu sieci w watach>,
            },
            "vpp_id": "<Identyfikator Wirtualnej Elektrowni>",
            "storage": {
                "energy_stored_Wh": <Energia Zmagazynowana w Watt-godzinach>,
                "energy_capacity_Wh": <Całkowita Pojemność Energetyczna w Watt-godzinach>,
                "mean_soc_perc": <Średni Poziom Naładowania w Procentach>,
                "active_power_W": <Moc Czynna w Watów>,
                "executed_power_W": <Ustalona Moc Wysłana do Urządzeń w Watów>,
                "executed_policy": <Polityka Wykonana przez Kontroler>,
                "max_charge_power_W": <Maksymalna Moc Ładowania w Watów>,
                "max_discharge_power_W": <Maksymalna Moc Rozładowania w Watów>,
                "today_charged_Wh": <Energia Naładowana Dziś w Watt-godzinach>,
                "today_discharged_Wh": <Energia Rozładowana Dziś w Watt-godzinach>,
                "nr_devices": <Liczba Zainstalowanych Urządzeń Zmagazynowanych>
            },
            "solar": {
                "active_power_W": <Moc Czynna Solarna w Watów>,
                "executed_power_W": <Ustalona Moc Wysłana do Urządzeń w Watów>,
                "executed_policy": <Polityka Wykonana przez Kontroler>,
                "capacity_W": <Pojemność Solarnego Systemu w Watów>,
                "today_energy_Wh": <Energia Wyprodukowana Dziś w Watt-godzinach>,
                "nr_devices": <Liczba Zainstalowanych Urządzeń Solarnych>
            },
            "heat_pump": {
                "executed_policy": <Polityka Wykonana przez Kontroler>,
                "operation_modes": <Tryby Pracy Pompy Ciepła>,
                "executed_power_W": <Ustalona Moc Wysłana do Urządzeń w Watów>,
                "nr_devices": <Liczba Zainstalowanych Urządzeń Pompy Ciepła>
            },
            "switched_load": {
                "executed_policy": <Polityka Wykonana przez Kontroler>,
                "devices_on": <Liczba Włączonych Urządzeń>,
                "devices_off": <Liczba Wyłączonych Urządzeń>,
                "executed_power_W": <Ustalona Moc Wysłana do Urządzeń w Watów>,
                "nr_devices": <Liczba Zainstalowanych Urządzeń Zwiększonego Obciążenia>
            },
            "variable_load": {
                "executed_policy": <Polityka Wykonana przez Kontroler>,
                "executed_power_W": <Ustalona Moc Wysłana do Urządzeń w Watów>,
                "active_power_W": <Moc urządzenia w Watów>,
                "ev_requiring_charge": <Czy EV wymaga ładowania>,
                "currentL1_A": <Prąd urządzenia na fazie 1 w Amperach>,
                "currentL2_A": <Prąd urządzenia na fazie 2 w Amperach>,
                "currentL3_A": <Prąd urządzenia na fazie 3 w Amperach>,
                "executed_current_A": <Ustalony Prąd Wysłany do Urządzeń w Amperach>,
                "today_charged_Wh": <Energia Naładowana Dziś w Watt-godzinach>,
                "today_discharged_Wh": <Energia Rozładowana Dziś w Watt-godzinach>,
                "total_charged_Wh": <Łączna Energia Naładowana w Watt-godzinach>,
                "total_discharged_Wh": <Łączna Energia Rozładowana w Watt-godzinach>,
                "min_charge_current_A": <Minimalny Prąd Ładowania w Amperach>,
                "max_charge_current_A": <Maksymalny Prąd Ładowania w Amperach>,
                "allow_zero_current": <Czy Ładowarka Obsługuje Wstrzymanie>,
            }
        },
        "response_code": <Kod Odpowiedzi>
    },
    "fields": {},
    "requestTime": "<Znacznik Czasu Unix>",
    "time": "<Znacznik Czasu Unix>",
    "siteNodeId": "<SN Kontrolera>_site_0"
}
            - executed_policy (Str): Polityki, które zostały zastosowane do urządzeń kontrolowanych,
            - executed_power_W (Float): Suma całkowitej mocy żądanej od zasobów, wysyłanej przez nasz algorytm sterowania.
            - active_power_W (Float): Reprezentuje aktualną aktywną moc w sieci w watach.
            - ev_requiring_charge (Bool): Czy EV wymaga ładowania. (Czy samochód jest podłączony).
            - currentL1_A (Float): Prąd urządzenia na fazie 1 w Amperach.
            - currentL2_A (Float): Prąd urządzenia na fazie 2 w Amperach.
            - currentL3_A (Float): Prąd urządzenia na fazie 3 w Amperach.
            - executed_current_A (Float): Suma całkowitego prądu żądanego od zasobów, wysyłanego przez nasz algorytm sterowania.
            - today_charged_Wh (Float): Energia naładowana do zasobów ładowarki EV dzisiaj. Uwaga: Dzisiaj podane jest w czasie UTC.
            - today_discharged_Wh (Float): Energia rozładowana z zasobów ładowarki EV dzisiaj. Uwaga: Dzisiaj podane jest w czasie UTC.
            - total_charged_Wh (Float): Całkowita energia naładowana do zasobów ładowarki EV.
            - total_discharged_Wh (Float): Całkowita energia rozładowana z zasobów ładowarki EV.
            - min_charge_current_A (Float): Minimalny prąd, przy którym EV może być ładowany.
            - max_charge_current_A (Float): Maksymalny prąd, przy którym EV może być ładowany.
            - allow_zero_current (Bool): Czy ładowarka EV pozwala na wstrzymanie.
        - nodeId (Object):
            - Jeśli nodeId jest zawarty w poleceniu, informacja zwrotna będzie zawierać odpowiedni stan urządzenia.
    - response_code (Int):
        - Wskazuje status operacji. Kod odpowiedzi 0 zazwyczaj oznacza sukces, podczas gdy inne wartości mogą wskazywać różne typy błędów lub informacji o statusie (te powinny być szczegółowo opisane w osobnym odniesieniu).

### Przykład Ładunku Informacji Zwrotnej
Oto przykład komunikatu zwrotnego po poleceniu ustawienia różnych punktów mocy:

<ClickableImage src="/img/generic/mqtt-example-feedback.png" alt="Obraz 1" maxWidth="450px" />

Ta informacja zwrotna demonstruje bieżący stan operacyjny systemu po wykonaniu punktów ustawienia, wskazując wpływ na generację energii słonecznej, magazynowanie i ogólną interakcję z siecią.

## Obsługiwane wersje MQTT i zachowanie w przypadku nieautoryzowanych tematów
Podczas korzystania z MQTT ważne jest uwzględnienie różnic w specyfikacjach pomiędzy wersjami 3.1, 3.1.1 i 5.0, szczególnie w odniesieniu do zachowania brokera, gdy klienci publikują na nieautoryzowanych tematach.

Zgodnie z specyfikacją MQTT 3.1.1 (zobacz OASIS MQTT 3.1.1 Specification, sekcja MQTT-3.3.5-2), broker musi zakończyć połączenie, gdy tylko klient wyśle PUBLISH do tematu, do którego nie ma uprawnienia. To zachowanie może prowadzić do nieoczekiwanych rozłączeń dla klientów próbujących publikować na źle skonfigurowanych lub nieautoryzowanych tematach.

W MQTT 3.1 ten wymóg nie występuje. Gdy klient publikuje na nieautoryzowanym temacie w tej wersji, broker zazwyczaj ignoruje wiadomość (ciche odrzucenie) bez przerywania połączenia. Umożliwia to w pewnych przypadkach bardziej odpowiednie użycie MQTT 3.1, gdy odporność na błędy konfiguracyjne lub tymczasowo brakujące uprawnienia jest ważniejsza niż ścisłe egzekwowanie bezpieczeństwa.

Chociaż MQTT 5.0 wprowadza możliwość pracy z kodami przyczyn (takimi jak PUBACK z powodem odmowy), wymaga to wsparcia zarówno po stronie klienta, jak i serwera. Migracja do MQTT 5.0 wiąże się z dodatkowymi kosztami wdrożenia.

__Konsekwencje ignorowania zgodności:__
Jeśli klient łączy się za pomocą MQTT 3.1.1 i próbuje publikować wiadomości na nieautoryzowanych tematach, broker nagle zakończy sesję. Może to prowadzić do niestabilności, utraty łączności lub zwiększonego obciążenia z powodu powtarzających się prób ponownego połączenia.

__Zalecane podejście:__
Dla systemów, w których klienci mogą (tymczasowo) próbować publikować na nieautoryzowanych tematach lub tam, gdzie obsługa błędów nie jest ściśle wdrożona, zalecamy korzystanie z MQTT 3.1. To zapewnia bardziej stabilne połączenia i unika niezamierzonych rozłączeń podczas działania.